Thank you @EastSun5566 !

It looks like there is a subtle bug in delete: if the first id to delete is not known, but others are known, none of them will be deleted. This is due to:

I've pushed a unit test demonstrating the issue. Since deleting unknown ids should be rare, it's okay to skip the fast path in this case and fall back on calling deleteOne.

The other thing I wonder is: how hard would it be to also optimize the case where the deleted ids are spread across several leaf nodes? Something like: bulk-delete as many as you can in the first leaf, then if you're not done, call locate again on the next id to delete, etc. It's okay to skip this fast path entirely if you encounter an unknown id.

Oh, you're right! First, I implemented a quick fix if first id to delete is not known should fall back to deleting one by one:

if (located !== null) {
 // bulk delete
}

// fall back to delete one by one

Something like: bulk-delete as many as you can in the first leaf, then if you're not done, call locate again on the next id to delete, etc. It's okay to skip this fast path entirely if you encounter an unknown id.

Yeah, that makes total sense. Here's my approach:

I track currentId and ⁠remaining in a loop. For each iteration, I calculate how many ids can be deleted in the current leaf, then bulk delete them. If bulk deletion isn't possible, I fall back to deleting one by one. Then I move to the next leaf and repeat until ⁠remaining reaches 0:

while (remaining > 0) {
  const located = ans.locate(currentId);
  
  if (located === null) {
    // skip and move to next
    continue;
  }

  // calculate how many ids can be deleted in this leaf
  if (canDeleteInLeaf) {
    // bulk delete and move to next
  } else {
    // fallback: delete one by one
  } 
}

I also added two simple tests that demonstrate bulk delete / undelete across multiple leaves. All existing tests pass.
What do you think?